|
|
| Author |
Thread Statistics | Show CCP posts - 11 post(s) |
|
CCP Prism X
C C P
C C P Alliance
487
   |
Posted - 2012.01.16 15:37:00 -
[1] - Quote
Transmission coded whilst listening to the most awesomest performance of the last century.
I've been doing some API work over the past week that should surface with Crucible 1.5 later this month. I thought I'd start off by introducing the changes as soon as possible so any interested parties could start making good use of them. I'll have Stillman come around to this topic and post about their availability on the testapi when they have been deployed there and basic testing has been passed. Why waste your time with my horrendously broken code, eh? 
There are also some internal changes on the horizon for the API project. More on that below.
Feature Additions
Item Location API Added
/char/Locations.xml.aspx
/corp/Locations.xml.aspx
Both these call require a full legacy key or a CAK key with explicit permissions. Any call to them must be followed by the input variable ids which is a comma seperated list of itemIDs that must be owned by the key owner (supplied as characterID for the char call if the key is not bound to a single character). Furthermore, each and every ID passed in must be a valid location (possiblity to exist in space as a standalone item).
Call will return the items name (or its type name if no user defined name exists) as well as their x,y,z coordinates. Coordinates should all be 0 for valid locations located inside of stations. Crab people, crab people, look like people, taste like crab. This can thus be used to get your ship names, POS module names and coordinates (to group stuff.. yes, I finally lived up to my Fan Fest promise and can thus show my face on the next one!).
I cannot stress enough that supplying IDs that are not valid locations or do not belong to the supplied owner (wether explicitly supplied or implied from key) will result in a completely empty result set! I know this is less than user friendly but experience has shown anything else leads to constant scraping.
Cache timer on production services: 60 minutes.
A new access check box will appear on the support website for this call, dechecked for all existing keys of course.
Type Name API Added
/eve/typeName.xml.aspx
I noticed that the CharacterName call was no longer servicing typeIDs. So I added this call to do that for mobile apps that cannot ship with the type part of the SDE. Call signature is just like CharacterNames, requires no access and caches for all eternity as type names do not tend to change.
Corporation Member Tracking Changed
The access to this call for CAK keys has now been split between LIMITED and EXTENDED. All currently existing keys will be switched to LIMITED mode for security reasons. To request the extended view on a key that allows that an additionial parameter of extended=1 will have to be supplied.
This had to be done as all CAK corporation keys are director level keys and thus all CAK keys were exposing the sensitive part of the return set. This change does not affect legacy keys.
Defect Fixes
Confusing CharacterID call returns
When a character was renamed, and the CharacterID call queried with the new name the result set would most probably contain the old name paired with the characterID. This is somewhat confusing when you supply 100 names and get two ids back which do not match to any name in your list.
Now, the CharacterID and CharacterName apis will not return confusing result sets like this. They will also strive to realize when a name has changed and flush it from cache but that is only possible under specific circumstances so there is no guarantee of which name will be returned in the case of renamed characters. As a reminder we always flush the cache between major updates.
Confusing KillLogs error messages
Error messages in the Kill mail API were less informative than they should be. They have thus been changed to reflect the following:
- Error code 119: Kill Logs only go a month back.
- Error code 120: The expected killID, that has been returned, should be supplied rather than whatever was supplied.
- Error Code 118: Refresh kill log with no killID supplied for most recent kills.
- Error Code 119 and 120: Reminder that each application should have their private kill log key.
Confusing Journal and Transaction error messages
When passing in transactionIDs that the underlying transaction walker does not recognize, the code will do its best to approximate desired output and return that rather than just error. To high an ID will refresh the most recent transactions, too low will just use the oldest transactionID and a nonexistant one that fits between the preceeding two ranges will approximate to the closest transactionID in the walker.
Furthermore, asking for the single most recent transactions, and then requesting the two most recent transaction on the same walker will now return the two most recent transactions rather than crap out. Previously loading up a single record frontpage would demand that you pass in fromIDs to continue walking back in the transaction history.
All comments apply to both transaction and journal APIs.
CCP Stillman will come around to this topic and announce the new additions (and perhaps defect fixes) having been deployed to SISI and tested.
~ CCP Prism X
EVE Database Developer
If anything in this post was informative or could be considered as 'good news' to you - chances are you've misread it. |
|
|
CCP Prism X
C C P
C C P Alliance
487
|
Posted - 2012.01.16 15:37:00 -
[2] - Quote
Post Reserved for Project Change announcement.
~ CCP Prism X
EVE Database Developer
If anything in this post was informative or could be considered as 'good news' to you - chances are you've misread it. |
|
|
CCP Prism X
C C P
C C P Alliance
488
|
Posted - 2012.01.16 18:08:00 -
[3] - Quote
Quote:Requesting a type name to id conversion...
I'll look into it.
POCOs should be owned by corporations (Disclaimer: Stuff changes without me knowing) so that should be accessible from a corp key.
But we're not talking about any POCO specific data being included in the item position calls nor any P.I. data. Those would be feature specific calls. I can look into some POCO data, but last time I checked the PI data required a running simulation so it is not very compatible with the current API implementation.
~ CCP Prism X
EVE Database Developer
If anything in this post was informative or could be considered as 'good news' to you - chances are you've misread it. |
|
|
CCP Prism X
C C P
C C P Alliance
500
|
Posted - 2012.01.26 08:14:00 -
[4] - Quote
Seems something went lost in translation during deployment. Call list and support site should reflect the call list on the test server: http://apitest.eveonline.com/api/calllist.xml.aspx
Looking into this.
~ CCP Prism X
EVE Database Developer
If anything in this post was informative or could be considered as 'good news' to you - chances are you've misread it. |
|
|
CCP Prism X
C C P
C C P Alliance
501
|
Posted - 2012.01.26 09:40:00 -
[5] - Quote
Not yet sadly. Issue has been found though, and fixed. It's just not fixed in cache and I cannot flush the production server one. Trying to get in touch with someone that can.
However, I do believe the support web does not use this cache so that you can now change your keys. Sadly I cannot check because nobody in their right mind would give me director status in a corporation.
~ CCP Prism X
EVE Database Developer
If anything in this post was informative or could be considered as 'good news' to you - chances are you've misread it. |
|
|
CCP Prism X
C C P
C C P Alliance
501
|
Posted - 2012.01.26 10:51:00 -
[6] - Quote
Turns out stuff got lost in translation again. Manually updated the stuff myself.
http://api.eveonline.com/api/CallList.xml.aspx Now show the extended and limited tracking as well as the new location calls.
Terribly sorry for this delay.
I really wanted my last API deployment to go smoothly. 
~ CCP Prism X
EVE Database Developer
If anything in this post was informative or could be considered as 'good news' to you - chances are you've misread it. |
|
|
CCP Prism X
C C P
C C P Alliance
501
|
Posted - 2012.01.26 11:35:00 -
[7] - Quote
No I don't.. not while you cannot assign these masks to your keys on the support website.
~ CCP Prism X
EVE Database Developer
If anything in this post was informative or could be considered as 'good news' to you - chances are you've misread it. |
|
|
CCP Prism X
C C P
C C P Alliance
501
|
Posted - 2012.01.26 11:44:00 -
[8] - Quote
Stuff should be on the up and up now.
Still terribly sorry for this delay.. there's a massive snow day here in Iceland so a whole lot of people are working from home.
~ CCP Prism X
EVE Database Developer
If anything in this post was informative or could be considered as 'good news' to you - chances are you've misread it. |
|
|
CCP Prism X
C C P
C C P Alliance
503
|
Posted - 2012.01.26 15:44:00 -
[9] - Quote
No, you should not be getting the same coordinates for all the structures (although they will clearly be quite similar).
If I somehow managed to link POS structures to their control tower so that I could accidentally return the same coordinates for the structures as I do for the towers.. then I have managed to accidentally solve a problem that's been bothering me for a long time. 
I'm usualy not that lucky.
~ CCP Prism X
EVE Database Developer
If anything in this post was informative or could be considered as 'good news' to you - chances are you've misread it. |
|
|
CCP Prism X
C C P
C C P Alliance
505
|
Posted - 2012.01.30 08:21:00 -
[10] - Quote
The maximum limit on all ids element calls is 250. At least that is the maximum for locations. I'm pretty sure that's the constant used in all the similar calls as well. Ofc if you're requesting a nine digit typeID 250 times you'll probably exceed the maximum URL length.
No, there are no 9 digit typeIDs yet.
~ CCP Prism X
EVE Database Developer
If anything in this post was informative or could be considered as 'good news' to you - chances are you've misread it. |
|
|
|
|
|
| |
|